Docket No.: SUN-P4182 
(811173-000118) 

REMARKS/ARGUMENTS 

The Office Action mailed April 29, 2004 has been carefully considered. Reconsideration 
in view of the following remarks is respectfully requested. 

Regarding Amendments 

The abstract has been amended to correct minor errors noted in the Office Action. These 
corrections are of a clerical nature and do not add "new matter". 

Claim Status and Amendment to the Claims 

Claims 84 and 87 have been cancelled, without prejudice or disclaimer of the subject 
matter contained therein. 

Claims 1-83 and 85-86 are now pending. 

No claims stand allowed. 

The 35 U.S.C. SI 12 Rejection 

Claims 84 and 87 stand rejected under 35 U.S.C. §112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which the 
Applicant regards as the invention. 1 With this Amendment, claims 84 and 87 have been 
cancelled without prejudice or disclaimer, thus rendering the 35 U.S.C §112 rejection moot. 
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Judicially-Created Double Patenting 

Claims 1-87 were rejected pursuant to the judicially-created doctrine of obviousness-type 
double patenting as being unpatentable over claims 1-77 of commonly assigned copending U.S. 
patent application serial number 09/661,581. Submitted herewith is a terminal disclaimer in 
accordance with 37 CFR 1.321 (b) and (c). Withdrawal of this rejection is respectfully 
requested. 



The 35 U.S.C. §103 Rejection 

Claims 1, 23, 45, 54, 63, 73, and 82-87 stand rejected under 35 U.S.C. § 103(a) as being 
allegedly unpatentable over Chan et al. 2 in view of CHneetaL 3 , among which claims 1, 23, 45, 
54, 63, 73, 82, and 85 are independent claims. This rejection is respectfully traversed. 

According to the Manual of Patent Examining Procedure (M.P.E.P.), 

To establish a prima facie case of obviousness, three basic criteria must be met. First 
there must be some suggestion or motivation, either in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art, to modify the reference 
or to combine reference teachings. Second, there must be a reasonable expectation of 
success. Finally, the prior art reference (or references when combined) must teach or 
suggest all the claim limitations. The teaching or suggestion to make the claimed 
combination and the reasonable expectation of success must both be found in the prior 
art, not in the applicant's disclosure. 4 

Specifically, the Office Action contends that the elements of the presently claimed 
invention are disclosed in Chan et al. except that Chan et al. does not teach binary compatibility. 5 
The Office Action further contends that Cline et al. teaches binary compatibility and that it 
would be obvious to one having ordinary skill in the art at the time of the invention to 



1 Office Action dated April 7, 2004, ^ 5. 

2 U.S. Patent No. 6,005,942. 

3 U.S. Patent No. 5,313,616. 
4 M.P.E.P§2143. 
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incorporate Cline et al. into Chan et al. in order to ensure that one's application program would 
run on any vendor's certified compatible computer system. 6 The Applicants respectfully 
disagree for the reasons set forth below. 



Claim 1 recites: 

A method for remote incremental program verification, said method comprising: 
receiving content verified by at least one content provider, said at least one content 
provider including an applet provider, a device manufacturer, a device issuer and a 
trusted post-issuance installer, said content including at least one program unit, each 
program unit comprising an Application Programming Interface (API) definition file 
and an implementation, each API definition file defining items in its associated 
program unit that are made accessible to one or more other program units, each 
implementation including executable code corresponding to said API definition file, 
said executable code including type specific instructions and data, said verification 
including determining binary compatibility of earlier program unit implementations 
with later program unit implementations; 
installing said content on a resource-constrained device; 
issuing said resource-constrained device to an end user; and 
allowing post-issuance installation of verified content on said resource-constrained 
device by said trusted post-issuance installer, said post-installation occurring after 
said issuance. 

The Examiner states: 

For claim 1, (Chan, Fig 3A, col 4 lines 59-67, col 7 lines 22-25, co 10 lines 2730, col 19 
lines 25-30, col 18 lines 30-40, col 3 lines 30-40, col 16 lines 7-15). Chan does not 
specifically disclose the binary compatibility. However, Cline discloses the binary 
compatibility as claimed (Cline, column 4, lines 34-53). The modification would be 
obvious because one of the ordinary skill in the art would be motivated to ensure that 
their application program will run on any vendor's certified compatible computer 
system. 

The Applicant respectfully disagrees. Contrary to the Examiner's statement, the 
references cited by the Examiner do not disclose receiving content verified by at least one 
content provider, where the content comprises at least one program unit, and where each 



5 Office Action H 8. 

6 Office Action I] 8. 
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program unit comprises an Application Programming Interface (API) definition file and an 
implementation. Rather, Chan et al. discloses: 

The applet Install File must contain all information that is required by the card in 
order to receive the applet, store it in non volatile storage and make it ready to run. This 
mandatory data includes the following: name or identifier of the applet; identification of 
hardware and software requirements (version of virtual machine, system class and system 
framework); link references to libraries and classes in ROM that need to be resolved; link 
references to libraries/class/functions in non volatile that need to resolved; link references 
within the applet that need to be resolved; fix ups for data references that need to be 
resolved; entry points for "process" and "install" methods; and proof of ownership, 
origin, and completeness and correctness. Optional information includes memory 
requirements, debug information and any potential terminal related information. 

The applet development process begins as soon as a concept of the desired applet 
is formulated. Once formulated, the concept must go through a number of stages before 
becoming a full fledged working and installable applet. An applet consists of two primary 
elements; the applet's process method; and the applet's install method. The applet 
development process (executable) is considered complete after creating and securely 
delivering the Install File. This development process may vary by organization but in 
general consists of the following steps: applet requirements gathering and definition; 
applet specification is developed from requirements; source code is developed from 
specification; managing applet source code, testing, approving; translate applet source 
code into card executable code; conversion to card byte code; card byte code verification; 
code linking and reference resolution; and signature creation. 

The results of the translation process is the Install File. The Install File contains 
the card byte code that is to be executed by the card. The purpose of this file may be one 
or more of the following: input to the ROM image (masking); input to tho initialization 
procedure (pre issuance load); and distribution for post issuance load (Secure Install). 
The Install File format and its contents are target system independent. The result of an 
applet development process is a target system independent signed Install File that 
contains the complete information need for loading an applet onto a card. The applet 
executable is contained within a single Install File. This Install File can be used for any 
of the following: the masking process; the initialization process; or the Secure Install 
process. 8 

Thus, Chan et al. discloses an "Install File" that contains card byte code that is to be 
executed by the card. Whereas claim 1 requires that the received content comprises at least one 
program unit, and that each program unit comprises both an API definition file and an 
implementation. Claim 1 further specifies that the API definition file defines items in its 



7 Office Action 1J8. 
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associated program unit that are made accessible to one or more other program units. This is not 
shown in Chan et al. in as complete detail as required by claim 1. 

The Examiner is reminded that the mere absence from a reference of an explicit 
requirement of a claim cannot be reasonably construed as an affirmative statement that the 
requirement is in the reference. 9 For this reason, the 35 U.S.C. § 103 of claims 1-87 is 
unsupported by the art and should be withdrawn. 

Claim 1 also requires allowing post-issuance installation of verified content on said 
resource-constrained device by said trusted post-issuance installer, said post-installation 
occurring after said issuance. This is not shown in the cited references in as complete detail as 
required by claim 1 . In fact, neither Chan et al nor Cline et al. distinguishes between a trusted 
post-issuance installer and an untrusted post-issuance installer. For this additional reason, the 35 
U.S.C. § 103 rejection of claim 1 is unsupported by the art and must be withdrawn. 

Claims 45, 63, and 82 

Claims 45, 63, and 82 also include substantially the same distinctive features as claim 1. 
Claim 1 being allowable, claims 45, 63, and 82 must also be allowable. 

Claims 23, 54, 73, and 85 

Like claim 1, claims 23, 54, 73, and 85 require that the received content comprises at 
least one program unit, and that each program unit comprises both an API definition file and an 

8 Chan et al. col. 19 line 31 to col. 20 line 10. (emphasis added) 

9 In re Evanega, 829 F.2d 1 1 10, 4 USPQ2d 1249 (Fed. Cir. 1987). 
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implementation. Thus, the argument made for claim 1 applies here as well. Claim 1 being 
allowable, claims 23, 54, 73, and 85 must also be allowable. 

Additionally, claims 23, 54, 73, and 85 recite in part allowing post-issuance installation 
of verified content on a resource-constrained device by an untrusted post-issuance installer. This 
is not shown in Chan et al. in as complete detail as required by claim 1. In fact, neither Chan et 
aL nor Cline et al. distinguishes between a trusted post-issuance installer and an untrusted post- 
issuance installer. For this additional reason, the 35 U.S.C. § 103 rejection of claims 23, 54, 73, 
and 85 is unsupported by the art and must be withdrawn. 

Dependent Claims 83 and 86 

Claims 83 and 86 depend from claims 82 and 85, respectively. Claims 82 and 85 being 
allowable, claims 83 and 86 must also be allowable for at least the same reasons. 

Accordingly, it is respectfully requested that the rejection of claims under 35 U.S.C. § 
103 be withdrawn. In view of the foregoing, it is respectfully asserted that the claims are now in 
condition for allowance. 

If, in the opinion of the Examiner, an interview would expedite the prosecution of this 
application, the Examiner is invited to call the undersigned attorney at the number indicated 
below. 
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The Commissioner is hereby authorized to charge any fees which may be required, or 
credit any overpayment, to Deposit Account Number 50-1698. 



Dated: July 13,2004 



Thelen Reid & Priest LLP 
P.O. Box 640640 
San Jose, CA 95164-0640 
Tel. (408) 292-5800 
Fax. (408) 287-8040 



Respectfully submitted, 
THELEN REDD & PRIEST, LLP 




John P. Schaub 
Reg. No. 42,125 
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